Skip to main content

Commulative Document

ZM APIs Technical Documentation

  1. Service: Metadata
    1. Base URL:
      http://zm.irdresearch.org/mrest/metadata
  1. Description
    The Metadata Service is a critical API for syncing data within the ZM mobile application. This service provides essential data related to:

  • Locations

  • Vaccination Centers

  • Programs

  • Equipment (e.g., fridge tags)

  • Vaccines and Vaccine Pre-requisites

  • Vaccine Stock

  • Location Types

  • User Roles and Permissions

  • Vaccinator Users

    This API is integral for the functioning of the mobile app, as syncing the latest metadata is necessary for accurate operation and data management.

  1. Request Format

    All requests must be sent using HTTP GET method.

  1. Response Format
  • Content-Type: application/json
  • Success Response: A 200 OK HTTP status code with the appropriate JSON response body.
  • Failure Response: A 200 OK HTTP status code with no JSON content, only a code value of 2 to indicate failure due to an incomplete operation or unknown reasons.
  • Server Error Response: A 500 Internal Server Error HTTP status code when a server-side error occurs.

  1. Dependencies​

    The Metadata API fetches data from multiple related tables in the system, including:

  • Users

  • Vaccinators

  • Locations and Location-Related Tables

  • Roles and Role Permissions

  • Vaccines and Vaccine-Related Tables

  • Stock Management

    Each of these components is crucial for proper synchronization and the overall functionality of the ZM application.

  1. Schema​

    Below are the key entities utilized by the Metadata Service:

    1. Location​
    2. LocationType​
    3. VaccinationCenter​
    4. Vaccine​
    5. VaccineGap​
    6. VaccinePrerequisite​
    7. User​
    8. Program​
    9. Role​
    10. VaccinatorDailyStock​
    11. Equipment​
    12. EquipmentType​
    13. Organization​

Flow Chart :

Locale Dropdown​

  1. Service: Enrollment (Child)
    1. Base URL:
      http://zm.irdresearch.org/mrest/enrollment
  1. Description
    The Enrollment Service is designed to facilitate the enrollment of children into the ZM system through the mobile application. The service saves critical child-related data into various database tables, ensuring accurate record-keeping for child health and vaccination data. This service is a core component of the application, supporting the collection and storage of child enrollment information.

  • Child

  • Child Analysis

  • Vaccination

  • Address

  • Contact Number

  • Identifier

  • MCCT visit (Non Mandatory)

    The service enables the collection of key data points that include personal information, vaccination status, and associated child health metrics.

  1. Request Format

    All requests must be sent using HTTP POST method.

  1. Response Format
  • Content-Type: application/json
  • Success Response: A 200 OK HTTP status code with the appropriate JSON response body.
  • Failure Response: A 200 OK HTTP status code with no JSON content, only a code value of 2 to indicate failure due to an incomplete operation or unknown reasons.
  • Server Error Response: A 500 Internal Server Error HTTP status code when a server-side error occurs.

  1. Dependencies​

    The child enrollment API stores data into multiple tables in the system, including:

  • Child
  • Child Analysis
  • Vaccination
  • Address
  • Contact Number
  • Identifier
  • MCCT Visit

  1. Schema​

    Below are the key entities utilized by the Enrollment Service:

  2. Child

  3. Child Analysis

  4. Vaccination

  5. Address

  6. Contact Number

  7. Identifier

  8. MCCT Visit

FlowChart:

Locale Dropdown

  1. Service: Followup (Child)
    1. Base URL:
      http://zm.irdresearch.org/mrest/followup
  1. Description
    The Follow-Up Service is designed to facilitate the tracking and follow-up of enrolled children in the ZM system through the mobile application. This service updates or adds new data regarding the child's health, vaccination status, and other key metrics after the initial enrollment. It is a critical part of ensuring ongoing monitoring and data collection for each child’s health journey, supporting healthcare providers with up-to-date information.
    The service allows updates to data related to the following key areas:

  • Child

  • Child Analysis

  • Vaccination

  • Address

  • Contact Number

  • Identifier

  • MCCT Visit (Non-Mandatory)

    Through follow-up, the service ensures that information regarding a child's health, vaccination schedule, and other data points is kept updated. This ongoing data collection supports continuous healthcare interventions and monitoring.

  1. Request Format

    All requests must be sent using HTTP POST method.

  1. Response Format
  • Content-Type: application/json
  • Success Response: A 200 OK HTTP status code with the appropriate JSON response body.
  • Failure Response: A 200 OK HTTP status code with no JSON content, only a code value of 2 to indicate failure due to an incomplete operation or unknown reasons.
  • Server Error Response: A 500 Internal Server Error HTTP status code when a server-side error occurs.

  1. Dependencies​

    The child follow-up API stores data into multiple tables in the system, including:

  • Child
  • Child Analysis
  • Vaccination
  • Address
  • Contact Number
  • Identifier
  • MCCT Visit

  1. Schema​

    Below are the key entities utilized by the Follow-Up Service:

  2. Child

  3. Child Analysis

  4. Vaccination

  5. Address

  6. Contact Number

  7. Identifier

  8. MCCT Visit

    This API documentation outlines the Follow-Up Service for children, detailing the request format, schema for key data entities, and expected response formats for success, failure, and error cases. The follow-up service plays a critical role in maintaining updated child health data within the system.

  1. Flow Chart​

Locale Dropdown

  1. Service: Fetch Child Information
    1. Base URL:
      http://zm.irdresearch.org/mrest/followup/organization
  1. Description
    The Follow-Up Service fetches detailed information about a child, including their demographic data, vaccination status, and any associated follow-up information through the mobile application. This service is designed to retrieve up-to-date child health and enrollment information, including past vaccinations, upcoming scheduled vaccinations, and follow-up data.
    The response includes essential child-related details, vaccination records, and other health information, which are vital for healthcare providers and mobile app users to track the child’s status and ensure timely healthcare interventions.

  1. Request Format

    This API uses the HTTP GET method to retrieve child data.

  • URL Parameters:
  • chlid: The unique identifier for the child.
  • organizationId: The organization identifier.
  1. Response Format
  • Content-Type: application/json
  • Success Response: A 200 OK HTTP status code with the appropriate JSON response body.
  • Failure Response: If the operation is incomplete or fails due to unknown reasons, a response code of 2 will be returned with no additional JSON content.
  • Server Error Response: A 500 Internal Server Error HTTP status code when a server-side error occurs.

  1. Dependencies​

    This API allows fetching detailed child information such as demographic data, vaccination history, and follow-up details for a specific child and organization. This is crucial for healthcare providers to stay informed about the child’s vaccination schedule and other important data.

  1. Flow Chart​

    Locale Dropdown

  1. Service: Fetch Women Information
    1. Base URL:
      http://zm.irdresearch.org/mrest/womenFollowup/organization
  1. Description
    The Women Follow-Up Service is designed to fetch detailed information about women, including their demographic details, health status, and follow-up data through the mobile application. This API allows healthcare providers and mobile app users to access the most up-to-date information about a woman's health, including medical history, enrollment details, and follow-up reminders.
    This service is used for tracking and managing the health of women enrolled in the system, ensuring that they receive the necessary care and attention at the right time
  1. Request Format

This API uses the HTTP GET method to retrieve women data.

  • URL Parameters:
  • women: The unique identifier for the women.
  • organizationId: The organization identifier.
  1. Response Format
  • Content-Type: application/json
  • Success Response: A 200 OK HTTP status code with the appropriate JSON response body.
  • Failure Response: If the operation is incomplete or fails due to unknown reasons, a response code of 2 will be returned with no additional JSON content.
  • Server Error Response: A 500 Internal Server Error HTTP status code when a server-side error occurs.

  1. Dependencies​

    This API allows fetching detailed women information such as demographic data, vaccination history, and follow-up details for a specific child and organization. This is crucial for healthcare providers to stay informed about the child’s vaccination schedule and other important data.

  1. Flow Chart​

Locale Dropdown

  1. Service: Enrollment (Women)
    1. Base URL:
      http://zm.irdresearch.org/mrest/womenEnrollment
  1. Description
    The Women Enrollment Service is responsible for enrolling women into the ZM system through the mobile application. This service ensures that women’s demographic and vaccination data are accurately recorded, which is essential for monitoring their health and immunization status.
  • Women
  • Women Analysis
  • Vaccination
  • Address
  • Contact Number
  • Identifier

  1. Request Format

    All requests must be sent using HTTP POST method.

  1. Response Format
  • Content-Type: application/json
  • Success Response: A 200 OK HTTP status code with the appropriate JSON response body.
  • Failure Response: A 200 OK HTTP status code with no JSON content, only a code value of 2 to indicate failure due to an incomplete operation or unknown reasons.
  • Server Error Response: A 500 Internal Server Error HTTP status code when a server-side error occurs.

  1. Dependencies​

    The child enrollment API stores data into multiple tables in the system, including:

  • Women
  • Women Analysis
  • Vaccination
  • Address
  • Contact Number
  • Identifier

  1. Schema​

    Below are the key entities utilized by the Enrollment Service:

  2. Women

  3. Women Analysis

  4. Vaccination

  5. Address

  6. Contact Number

  7. Identifier

  1. Follow up​

Locale Dropdown

  1. Service: Followup (Women)

    1. Base URL:
      http://zm.irdresearch.org/mrest/womenFollowup
  1. Description
    The Women Follow-Up Service is designed to fetch the latest follow-up information regarding a woman’s health and vaccination status. This service is used to track the status of vaccinations, health check-ups, and other important follow-up visits for women enrolled in the ZM system.
    The service allows updates to data related to the following key areas:

  • Women

  • Women Analysis

  • Vaccination

  • Address

  • Contact Number

  • Identifier

    Through follow-up, the service ensures that information regarding a women's health, vaccination schedule, and other data points is kept updated. This ongoing data collection supports continuous healthcare interventions and monitoring.

  1. Request Format

    All requests must be sent using HTTP POST method.

  1. Response Format
  • Content-Type: application/json
  • Success Response: A 200 OK HTTP status code with the appropriate JSON response body.
  • Failure Response: A 200 OK HTTP status code with no JSON content, only a code value of 2 to indicate failure due to an incomplete operation or unknown reasons.
  • Server Error Response: A 500 Internal Server Error HTTP status code when a server-side error occurs.

  1. Dependencies​

    The child follow-up API stores data into multiple tables in the system, including:

  • Women
  • Women Analysis
  • Vaccination
  • Address
  • Contact Number
  • Identifier

  1. Schema​

    Below are the key entities utilized by the Follow-Up Service:

  2. Women

  3. Women Analysis

  4. Vaccination

  5. Address

  6. Contact Number

  7. Identifier

    This API documentation outlines the Follow-Up Service for women, detailing the request format, schema for key data entities, and expected response formats for success, failure, and error cases. The follow-up service plays a critical role in maintaining updated women health data within the system.

  1. Flow Chart​

    Locale Dropdown

  1. Service: Adverse Event Resource

    1. Base URL:
      http://zm.irdresearch.org/mrest/adverseEvent
  1. Description
    The Adverse Event Service is responsible for collecting information regarding the side effects of a vaccination administered to a woman or child.

  1. Request Format

    All requests must be sent using HTTP POST method.

  1. Response Format

  • Content-Type: application/json
  • Success Response: A 200 OK HTTP status code with the appropriate JSON response body.
  • Failure Response: A 200 OK HTTP status code with no JSON content, only a code value of 2 to indicate failure due to an incomplete operation or unknown reasons.
  • Server Error Response: A 500 Internal Server Error HTTP status code when a server-side error occurs.

  1. Dependencies​

    The adverse event API stores data into multiple tables in the system, including:

  • childadverseeventvaccinationdetails
  • childadverseeventcomplains
  • tracking
  • Childadverseevent
  • womenadverseeventvaccinationdetails
  • womenadverseeventcomplains
  • Womenadverseevent

  1. Flow chart​

    Locale Dropdown

  1. Service: CCM Resource

    1. Base URL:
      http://zm.irdresearch.org/mrest/CCM

  1. Description
    The CCM Service is responsible for collecting and show information regarding the ILR temperatures. The api stores data from ILR device including the alarms and each day temperature.

  1. Request Format

    Requests must be sent using HTTP POST and HTTP GET method.

  1. Response Format

  • Content-Type: application/json
  • Success Response: A 200 OK HTTP status code with the appropriate JSON response body.
  • Failure Response: A 200 OK HTTP status code with no JSON content, only a code value of 2 to indicate failure due to an incomplete operation or unknown reasons.
  • Server Error Response: A 500 Internal Server Error HTTP status code when a server-side error occurs.

  1. Dependencies​

    The adverse event API stores data into multiple tables in the system, including:

  • Ilr
  • Ilr_ft_mapping
  • Ilrcheckin
  • Ilrmanufacturer
  • Ilrmodel
  • Ilrmonitoring
  • fridgetag
  • fridgetaginfo

  1. Flow chart for get​

Locale Dropdown

  1. Flow chart for post​

Locale Dropdown​

Locale Dropdown​

  1. Service: Zero Child Resource

  2. Base URL:
    http://zm.irdresearch.org/mrest/zeroChild

  1. Description
    The ZeroDose Service is responsible to reach out Zero-dose children (those who have not received any of the routine vaccinations), Zero Dose feature was incorporated in the ZM. Primarily focus of Zero-Dose is to collect data of such children and to provide them vaccinations to improve the risk of child deaths, disease outbreaks and medical impoverishment.

  1. Request Format

    Requests must be sent using HTTP POST and HTTP GET method.

  1. Response Format

  • Content-Type: application/json
  • Success Response: A 200 OK HTTP status code with the appropriate JSON response body.
  • Failure Response: A 200 OK HTTP status code with no JSON content, only a code value of 2 to indicate failure due to an incomplete operation or unknown reasons.
  • Server Error Response: A 500 Internal Server Error HTTP status code when a server-side error occurs.

  1. Dependencies​

    The adverse event API stores data into multiple tables in the system, including:

  • Zeroimmunizationchild

  1. Service: Login Resource

    1. Base URL:
      http://zm.irdresearch.org/mrest/login

  1. Description
    The Login Service is responsible to make the user login in to the ZM Application.

  1. Request Format

    Requests must be sent using HTTP POST method.

  1. Response Format

  • Content-Type: application/json
  • Success Response: A 200 OK HTTP status code with the appropriate JSON response body.
  • Failure Response: A 200 OK HTTP status code with no JSON content, only a code value of 2 to indicate failure due to an incomplete operation or unknown reasons.
  • Server Error Response: A 500 Internal Server Error HTTP status code when a server-side error occurs.

  1. Service: Attendance Checkin Resource

    1. Base URL:
      http://zm.irdresearch.org/unfepi/aws/api/attendance/checkInEvent

  1. Description
    The Attendance Checkin Service is responsible for marking in the attendance of a vacciantion.

  1. Request Format

    Requests must be sent using HTTP POST method.

  1. Response Format

  • Content-Type: application/json
  • Success Response: A 200 OK HTTP status code with the appropriate JSON response body.
  • Failure Response: A 200 OK HTTP status code with no JSON content, only a code value of 2 to indicate failure due to an incomplete operation or unknown reasons.
  • Server Error Response: A 500 Internal Server Error HTTP status code when a server-side error occurs.

  1. Dependencies​

    The attendance checkin API stores data into following table in the system, including:

  • attendance

  1. Flow Chart​

Locale Dropdown

  1. Service: Attendance Checkout Resource

    1. Base URL:
      http://zm.irdresearch.org/unfepi/aws/api/attendance/checkOutEvent

  1. Description
    The Attendance CheckOut Service is responsible for marking in the attendance of a vacciantion.

  1. Request Format

    Requests must be sent using HTTP POST method.

  1. Response Format

  • Content-Type: application/json
  • Success Response: A 200 OK HTTP status code with the appropriate JSON response body.
  • Failure Response: A 200 OK HTTP status code with no JSON content, only a code value of 2 to indicate failure due to an incomplete operation or unknown reasons.
  • Server Error Response: A 500 Internal Server Error HTTP status code when a server-side error occurs.

  1. Dependencies​

    The attendance checkout API stores data into following table in the system, including:

  • attendance

  1. Below are the given APIs that are dormant.

    1. Base URL:
      http://zm.irdresearch.org/mrest/campaign/enrollment
      http://zm.irdresearch.org/mrest/campaign/getAllActive
      http://zm.irdresearch.org/mrest/equipment
      http://zm.irdresearch.org/mrest/equipment/fetch
      http://zm.irdresearch.org/mrest/dfr
      http://zm.irdresearch.org/mrest/equipment/fetch
      http://zm.irdresearch.org/mrest/zipped/getdata/immunization
      http://zm.irdresearch.org/mrest/zipped/getdata/dhis
      http://zm.irdresearch.org/mrest/zipped/getdata/womendhis
      http://zm.irdresearch.org/mrest/evidence
      http://zm.irdresearch.org/mrest/followup-hepa/orgranization
      http://zm.irdresearch.org/mrest/mcctIncentive/getStatus
      http://zm.irdresearch.org/mrest/mcctIncentive/sendSMS
      http://zm.irdresearch.org/mrest/mcctIncentive/getIncentiveStatus
      http://zm.irdresearch.org/mrest/ResponseService
      http://zm.irdresearch.org/mrest/search
      http://zm.irdresearch.org/mrest/search/zerodose
      http://zm.irdresearch.org/mrest/womensearch
      http://zm.irdresearch.org/mrest/storeKeeper
      http://zm.irdresearch.org/mrest/dutyTour/add
      http://zm.irdresearch.org/mrest/dutyTour/fetch
      http://zm.irdresearch.org/mrest/inventory

  1. Below are the given APIs that will become dormant after mccts close out.

    1. Base URL:
      http://zm.irdresearch.org/mrest/mcctTicketing/getStatus

    http://zm.irdresearch.org/mrest/mcctTicketing/sendSMS

    http://zm.irdresearch.org/mrest/mcctTicketing/getIncentiveStatus

    http://zm.irdresearch.org/mrest/mcctTicketing/getChildDistrict

    http://zm.irdresearch.org/mrest/monitoring/getChildByOperator

    http://zm.irdresearch.org/mrest/monitoring/childinfo

    http://zm.irdresearch.org/mrest/monitoring/townsList